feat(seer): Read Seer project preferences from Sentry DB in Sentry endpoints#111594
Merged
feat(seer): Read Seer project preferences from Sentry DB in Sentry endpoints#111594
Conversation
Add read_preference_from_sentry_db() and bulk_read_preferences_from_sentry_db() to read Seer project preferences directly from Sentry's database instead of proxying to the Seer API. This is the foundation for cutting over reads behind the organizations:seer-project-settings-read-from-sentry feature flag. - Register organizations:seer-project-settings-read-from-sentry feature flag - Add SEER_PREFERENCE_OPTION_KEYS constant in projectoptions/defaults.py - Add build_repo_definition_from_project_repo() and build_automation_handoff() shared helpers using a Callable interface for option getters - Single read uses project.get_option() with caching - Bulk read uses ProjectOption.objects.get_value_bulk_id() with fallback to registered defaults via projectoptions.lookup_well_known_key() Co-Authored-By: Claude Sonnet 4 <noreply@anthropic.com> Made-with: Cursor
Cover read_preference_from_sentry_db and bulk_read_preferences_from_sentry_db with tests for unconfigured projects, repos with branch overrides, options-only projects, full and partial handoff configs, org scoping, and configured-vs-absent filtering. Co-Authored-By: Claude Sonnet 4 <noreply@anthropic.com> Made-with: Cursor
Contributor
Backend Test FailuresFailures on
|
read_preference_from_sentry_db now returns None for unconfigured projects (no explicit option keys set and no repos), matching the bulk function's behavior. bulk_read_preferences_from_sentry_db is simplified to delegate to the single-project reader. Uses ProjectOption.objects.isset() and project.get_option() which both go through get_all_values(), a cached lookup, instead of the previous get_value_bulk_id() approach that issued a separate DB query per option key bypassing the cache. This is efficient for the small-project-count callers (settings endpoints, org setup). Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The previous commit simplified bulk_read to delegate to the single-project reader, but that trades O(1) batched queries for O(N) per-project queries (one repo query + one cache/DB hit per project). The bulk function is called from configure_seer_for_existing_org which operates on all projects in an org, so N can be large. Keep the batched approach (1 repo query + 5 option queries total) for the bulk path, while the single-project reader uses the cached isset()/get_option() path which is efficient for its callers. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Contributor
Backend Test FailuresFailures on
|
Co-authored-by: Armen Zambrano G. <armenzg@users.noreply.github.com> Applied via @cursor push command
ebf3c34 to
259533a
Compare
Contributor
Backend Test FailuresFailures on
|
srest2021
added a commit
that referenced
this pull request
Apr 9, 2026
…entry DB (#111591) relates to AIML-2611, AIML-2610 Add `read_preference_from_sentry_db()` and `bulk_read_preferences_from_sentry_db()` helpers to read Seer project preferences directly from Sentry DB instead of Seer API. This is the foundation for cutting over reads behind the `organizations:seer-project-settings-read-from-sentry` feature flag. We don't actually use the helpers in this PR. WIP followup PR: #111594 ### Extra We return None if a project is unconfigured. Matching Seer's behavior ([single](https://github.com/getsentry/seer/blob/3cec03cac3abd9f1f26ac42296d6c870669c66f0/src/seer/automation/preferences.py#L54), [bulk](https://github.com/getsentry/seer/blob/3cec03cac3abd9f1f26ac42296d6c870669c66f0/src/seer/automation/preferences.py#L98)), "unconfigured" means we don't have any SeerProjectRepository rows _and_ none of the project options are set. We use `project.get_option` and `ProjectOptions.objects.isset` for single reads, and `ProjectOption.objects.get_value_bulk_id` for bulk read. Why: 1. `project.get_option` and `ProjectOptions.objects.isset` use cache. For a single project we want to check the cache first. 2. `ProjectOption.objects.get_value_bulk_id` is one DB query. For our bulk use cases (`OrganizationAutofixAutomationSettingsEndpoint` get/post, `configure_seer_for_existing_org`) where we may be querying many projects for a single org, we do max 5 option queries, one for each project option. It also returns None for missing options so we can easily tell which projects have configured options and which don't. --------- Co-authored-by: Claude Sonnet 4 <noreply@anthropic.com> Co-authored-by: Cursor Agent <cursoragent@cursor.com>
george-sentry
pushed a commit
that referenced
this pull request
Apr 9, 2026
…entry DB (#111591) relates to AIML-2611, AIML-2610 Add `read_preference_from_sentry_db()` and `bulk_read_preferences_from_sentry_db()` helpers to read Seer project preferences directly from Sentry DB instead of Seer API. This is the foundation for cutting over reads behind the `organizations:seer-project-settings-read-from-sentry` feature flag. We don't actually use the helpers in this PR. WIP followup PR: #111594 ### Extra We return None if a project is unconfigured. Matching Seer's behavior ([single](https://github.com/getsentry/seer/blob/3cec03cac3abd9f1f26ac42296d6c870669c66f0/src/seer/automation/preferences.py#L54), [bulk](https://github.com/getsentry/seer/blob/3cec03cac3abd9f1f26ac42296d6c870669c66f0/src/seer/automation/preferences.py#L98)), "unconfigured" means we don't have any SeerProjectRepository rows _and_ none of the project options are set. We use `project.get_option` and `ProjectOptions.objects.isset` for single reads, and `ProjectOption.objects.get_value_bulk_id` for bulk read. Why: 1. `project.get_option` and `ProjectOptions.objects.isset` use cache. For a single project we want to check the cache first. 2. `ProjectOption.objects.get_value_bulk_id` is one DB query. For our bulk use cases (`OrganizationAutofixAutomationSettingsEndpoint` get/post, `configure_seer_for_existing_org`) where we may be querying many projects for a single org, we do max 5 option queries, one for each project option. It also returns None for missing options so we can easily tell which projects have configured options and which don't. --------- Co-authored-by: Claude Sonnet 4 <noreply@anthropic.com> Co-authored-by: Cursor Agent <cursoragent@cursor.com>
Contributor
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit e2d9ecb. Configure here.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

Fixes AIML-2611
Depends on #111591
Behind
organizations:seer-project-settings-read-from-sentry, read Seer project preferences directly from ProjectOption + SeerProjectRepository instead of proxying to the Seer API. Part of Phase 3 of the Seer project preferences migration.Updated call sites:
Note: Generally I chose not to catch DB errors. We shouldn't be getting any. We'll roll out gradually and if something happens we should get a Sentry exception so I can fix it.